home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
protocol
/
standard
/
ccitt
/
1992
/
x
/
x25_4.asc
< prev
next >
Wrap
Text File
|
1993-07-14
|
87KB
|
3,767 lines
5.2.4 Clear request and clear indication packets
Figure 8/X.25 illustrates the format of clear request and clear indication
packets, in basic and extended formats.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) Logical channel group number
2 Logical channel number
3 Packet type identifier
0 0 0 1 0
PAGE70 Fascicle VIII.8 - X.25
0 1 1
4 Clearing cause
5 Diagnostic code a)
4 Address block b)
(see S 5.2.1)
Facility length b)
Facilites b)
Clear user data b)
a) This field is not mandatory in the basic format of clear request packets (see S
5.2.4.1).
b) Used only in the extended format (see S 5.2.4.2).
Note - Coded X001 (modulo 8) or X010 (modulo 128).
FIGURE 8/X.25
Clear request and clear indication packet format
5.2.4.1 Basic format
5.2.4.1.1 Clearing cause field
Octet 4 is the clearing cause field and contains the reason for the
clearing of the call.
In the clear request packets, the clearing cause field should be set by
the DTE to one of the following values:
bits: 8 7 6 5 4 3 2 1
value: 0 0 0 0 0 0 0 0
or: 1 X X X X X X X
where each X may be independently set to 0 or 1 by the DTE.
Fascicle VIII.2 - Rec. X.25 PAGE93
The DCE will prevent values of the clearing cause field other than those
shown above from reaching the other end of the call by either accepting the clear
request packet and forcing the clearing cause field to all zeros in the
corresponding clear indication packet, or considering the clear request as an
error and following the procedure described in Annex C.
The coding of the clearing cause field in clear indication packets is
given in Table 20/X.25.
TABLE 20/X.25
Coding of clearing cause field in clear indication packet
Bits
8 7 6 5 4 3 2 1
DTE originated 0 0 0 0 0 0 0 0
DTE originated a) 1 X X X X X X X
Number busy 0
PAGE70 Fascicle VIII.8 - X.25
0 0 0 0 0 0 1
Out of order 0 0 0 0 1 0 0 1
Remote procedure error 0 0 0 1 0 0 0 1
Reverse charging acceptance not 0 0 0 1 1 0 0
subscribed b)
Fascicle VIII.2 - Rec. X.25 PAGE93
1
Incompatible destination 0 0 1 0 0 0 0 1
Fast select acceptance not 0 0 1 0 1 0 0 1
subscribed b)
Ship absent c) 0 0 1 1 1 0 0 1
Invalid facility request 0 0 0 0
PAGE70 Fascicle VIII.8 - X.25
0 0 1 1
Acces barred 0 0 0 0 1 0 1 1
Local procedure error 0 0 0 1 0 0 1 1
Network congestion 0 0 0 0 0 1 0 1
Not obtainable 0
Fascicle VIII.2 - Rec. X.25 PAGE93
0 0 0 1 1 0 1
RPOA out of order b) 0 0 0 1 0 1 0 1
a) When bit 8 is set to 1, the bits represented by Xs are those included by the
remote DTE in the clearing or restarting cause field of the clear or restart
request packet respectively.
b) May be received only if the corresponding optional user facility is used.
c) Used in the conjunction with mobile maritime service.
PAGE70 Fascicle VIII.8 - X.25
5.2.4.1.2 Diagnostic code
Octet 5 is the diagnostic code and contains additional information on the
reason for the clearing of the call.
In a clear request packet, the diagnostic code is not mandatory.
In a clear indication packet, if the clearing cause field indicates "DTE
originated", the diagnostic code is passed unchanged from the clearing DTE. If
the clearing DTE has not provided a diagnostic code in its clear request packet,
then the bits of the diagnostic code in the resulting clear indication packet
will all be zero.
When a clear indication packet results from a restart request packet, the
value of the diagnostic code will be that specified in the restart request
packet, or all zeros in the case where no diagnostic code has been specified in
the restart request packet.
When the clearing cause field does not indicate "DTE originated", the
diagnostic code in a clear indication packet is network generated. Annex E lists
the codings for network generated diagnostics. The bits of the diagnostic code
are all set to 0 when no specific additional information for the clearing is
supplied.
Note - The contents of the diagnostic code field do not alter the meaning
of the cause field. A DTE is not required to undertake any action on the contents
of the diagnostic code field. Unspecified code combinations in the diagnostic
code field shall not cause the DTE to refuse the cause field.
5.2.4.2 Extended format
The extended format is used for clear request and clear indication packets
only when the DTE or the DCE need to use the called and/or calling DTE address
fields, the facility field and/or the clear user data field in conjunction with
one or several optional user facilities described in SS 6 and 7. The called DTE
address field is used only when the called line address modified notification
facility is used in clearing, in response to an incoming call or call request
packet.
When the extended format is used, the diagnostic code field, the DTE
address length fields and the facility length field must be present. Optionally,
the clear user data field may also be present.
5.2.4.2.1 Address block
The address block is described in S 5.2.1.
5.2.4.2.2 Facility length field
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and bit 1 is the
low order bit of the indicator.
5.2.4.2.3 Facility field
The facility field is present in the clear request or the clear indication
packet only in conjunction with one or several optional user facilities requiring
some indication in this packet.
The coding of the facility field is defined in SS 6 and 7.
The facility field contains an integral number of octets. The actual
maximum length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109 octets.
Note - It is for further study whether another value should be defined,
relative to the total number of octets in the packet.
5.2.4.2.4 Clear user data field
This field may be present only in conjunction with the fast select
facility (see S 6.16) or the call deflection selection facility (see S 6.25.2.2).
It has a maximum length of 128 octets in the first case, of 16 or 128 octets in
the second case: whether the maximum length is 16 or 128 octets when using the
call deflection selection facility is specified in S 6.25.2.2.
Note 1 - Some networks require the clear user data field to contain an
integral number of octets (see the note in S 3).
Note 2 - The network does not act on any part of the clear user data
field. See Recommendation X.244.
5.2.5 DTE and DCE clear confirmation packets
Figure 9/X.25 illustrates the format of the DTE and DCE clear confirmation
packets, in the basic or extended format.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) Logical channel group number
2 Logical channel number
3
Fascicle VIII.2 - Rec. X.25 PAGE93
Packet type identifier
0 0 0 1 0 1 1 1
4 Address block a)
(see S 5.2.1)
Facility length a)
Facilities a)
a) Used only in the extended format of DCE clear confirmation packets.
Note - Coded X001 (modulo 8) or X010 (modulo 128).
FIGURE 9/X.25
DTE and DCE clear confirmation packet format
The extended format may be used for DCE clear confirmation packets only in
conjunction with the charging information facility described in S 6.22. It is not
used for DTE clear confirmation packet.
5.2.5.1 Address block
The address block is described in S 5.2.1.
The calling and called DTE address length fields are coded with all zeros
and the called and calling DTE address fields are not present.
5.2.5.2 Facility length field
The octet following the address block indicates the length of the facility
field, in octets. The facility length indicator is binary coded and bit 1 is the
low order bit of the indicator.
5.2.5.3 Facility field
The coding of the facility field is defined in SS 6 and 7.
The facility field contains an integral number of octets. The actual
maximum length of this field depends on the facilities which are offered by the
network. However, this maximum does not exceed 109 octets.
Note - It is for further study whether another value should be defined,
relative to the total number of octets in the packet.
5.3 Data and interrupt packets
5.3.1 DTE and DCE data packets
Figure 10/X.25 illustrates the format of the DTE and DCE data packets.
Bits
8 7 6 5 4 3 2
PAGE70 Fascicle VIII.8 - X.25
1
Octet
s
1 General format identifier Logical channel group number
Q D 0 1
2 Logical channel number
3 P(R) M P(S) 0
User data
(Modulo 8)
Fascicle VIII.2 - Rec. X.25 PAGE93
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier Logical channel group number
Q D 1 0
2 Logical channel number
PAGE70 Fascicle VIII.8 - X.25
3 P(S) 0
P(R) M
4 User data
(When extended to modulo 128)
D Delivery confirmation bit
M More data bit
Q Qualifier bit
FIGURE 10/X.25
DTE and DCE data packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.3.1.1 Qualifier (Q) bit
Bit 8 of octet 1 is the qualifier (Q) bit.
5.3.1.2 Delivery confirmation (D) bit
Bit 7 of octet 1 is the delivery confirmation (D) bit.
5.3.1.3 Packet receive sequence number
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended,
are used for indicating the packet receive sequence number P(R). P(R) is binary
coded and bit 6, or bit 2 when extended, is the low order bit.
5.3.1.4 More Data bit
Bit 5 in octet 3, or bit 1 in octet 4 when extended, is used for the More
Data (M bit): 0 for no more data and 1 for
more data.
5.3.1.5 Packet send sequence number
Bits 4, 3 and 2 of octet 3, or bits 8 through 2 of octet 3 when extended,
are used for indicating the packet send sequence number P(S). P(S) is binary
coded and bit 2 is the low order bit.
5.3.1.6 User data field
Bits following octet 3, or octet 4 when extended, contain user data.
Note - Some networks require the user data field to contain an integral
number of octets (see the note in S 3).
5.3.2 DTE and DCE interrupt packets
Figure 11/X.25 illustrates the format of the DTE and DCE interrupt
packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) Logical channel group number
2 Logical channel number
3
PAGE70 Fascicle VIII.8 - X.25
Packet type identifier
0 0 1 0 0 0 1 1
4 Interrupt user data
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 11/X.25
DTE and DCE interrupt packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.3.2.1 Interrupt user data field
Octet 4 and any following octets contain the interrupt user data. This
field may contain from 1 to 32 octets.
Note - Some networks require the interrupt user data field to contain an
integral number of octets (see the note in S 3).
5.3.3 DTE and DCE interrupt confirmation packets
Figure 12/X.25 illustrates the format of the DTE and DCE interrupt
confirmation packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) Logical channel group number
2 Logical channel number
3 Packet type identifier
0 0 1
PAGE70 Fascicle VIII.8 - X.25
0 0 1 1 1
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 12/X.25
DTE and DCE interrupt confirmation packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.4 Flow control and reset packets
5.4.1 DTE and DCE receive ready (RR) packets
Figure 13/X.25 illustrates the format of the DTE and DCE RR packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier Logical channel group number
0 0 0 1
PAGE70 Fascicle VIII.8 - X.25
2 Logical channel number
3 P(R) 0 0 0 0 1
(Modulo 8)
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier Logical channel group number
Fascicle VIII.2 - Rec. X.25 PAGE93
0 0 1 0
2 Logical channel number
3 Packet type identifier
0 0 0 0 0 0 0 1
4 P(R) 0
(When extended to modulo 128)
FIGURE 13/X.25
DTE and DCE RR packet format
PAGE70 Fascicle VIII.8 - X.25
5.4.1.1 Packet receive sequence number
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended,
are used for indicating the packet receive sequence number P(R). P(R) is binary
coded and bit 6, or bit 2 when extended, is the low order bit.
5.4.2 DTE and DCE receive not ready (RNR) packets
Figure 14/X.25 illustrates the format of the DTE and DCE RNR packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier Logical channel group number
0 0 0 1
Fascicle VIII.2 - Rec. X.25 PAGE93
2 Logical channel number
3 P(R) 0 0 1 0 1
(Modulo 8)
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier
PAGE70 Fascicle VIII.8 - X.25
Logical channel group number
0 0 1 0
2 Logical channel number
Packet type identifier
3 0 0 0 0 0 1 0 1
4 P(R) 0
(When extended to modulo 8)
FIGURE 14/X.25
DTE and DCE RNR packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.4.2.1 Packet receive sequence number
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended,
are used for indicating the packet receive sequence number P(R). P(R) is binary
coded and bit 6, or bit 2 when extended, is the low order bit.
5.4.3 Reset request and reset indication packets
Figure 15/X.25 illustrates the format of the reset request and reset
indication packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier Logical channel group number
2 Logical channel number
3 Packet type identifier
0 0 0
PAGE70 Fascicle VIII.8 - X.25
1 1 0 1 1
4 Resetting cause
5 Diagnostic code a)
a) This field is not mandatory in reset request packets.
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 15/X.25
Reset request and reset indication packet format
5.4.3.1 Resetting cause field
Octet 4 is the resetting cause field and contains the reason for the
reset.
In reset request packets, the resetting cause field should be set by the
DTE to one of the following values:
bits: 8 7 6 5 4 3 2 1
value: 0 0 0 0 0 0 0 0
or: 1 X X X X X X X
where each X may be independently set to 0 or 1 by the DTE.
The DCE will prevent values of the resetting cause field, other than those
shown above, from reaching the other end of the virtual call or permanent virtual
circuit by either accepting the reset request packet and forcing the resetting
cause field to all zeros in the corresponding reset indication packet, or
considering the reset request as an error and following the procedure described
in Annex C.
The coding of the resetting cause field in a reset indication packet is
given in Table 21/X.25.
TABLE 21/X.25
Coding of resetting cause field in reset indication packet
Bits
8 7 6 5 4 3 2 1
DTE originated 0 0 0 0
Fascicle VIII.2 - Rec. X.25 PAGE93
0 0 0 0
DTE originated a) 1 X X X X X X X
Out or order b) 0 0 0 0 0 0 0 1
Remote procedure error 0 0 0 0 0 0 1 1
Local procedure error 0
PAGE70 Fascicle VIII.8 - X.25
0 0 0 0 1 0 1
Network congestion 0 0 0 0 0 1 1 1
Remote DTE operational b) 0 0 0 0 1 0 0 1
Network operational b) 0 0 0 0 1 1 1
Fascicle VIII.2 - Rec. X.25 PAGE93
1
Incompatible destination 0 0 0 1 0 0 0 1
Network out of order b) 0 0 0 1 1 1 0 1
a) When bit 8 is set to 1, the bits represented by Xs are those indicated
by the remote DTE in the resetting cause field (virtual calls and
permanent virtual circuits) or the restarting cause field (permanent
virtual circuits only) of the reset or restart request packet,
respectively.
b) Applicable to permanent virtual circuits only.
5.4.3.2 Diagnostic code
Octet 5 is the diagnostic code and contains additional information on the
reason for the reset.
In a reset request packet the diagnostic code is not mandatory.
In a reset indication packet, if the resetting cause field indicates "DTE
originated", the diagnostic code has been passed unchanged from the resetting
DTE. If the DTE requesting a reset has not provided a diagnostic code in its
reset request packet, then the bits of the diagnostic code in the resulting reset
indication packet will all be zeros.
When a reset indication packet results from a restart request packet, the
value of the diagnostic code will be that specified in the restart request
packet, or all zeros in the case where no diagnostic code has been specified in
the restart request packet.
When the resetting cause field does not indicate "DTE originated", the
diagnostic code in a reset indication packet is network generated. Annex E lists
the codings for network generated diagnostics. The bits of the diagnostic code
are all set to 0 when no specific additional information for the reset is
supplied.
Note - The contents of the diagnostic code field do not alter the meaning
of the cause field. A DTE is not required to undertake any action on the contents
of the diagnostic code field. Unspecified code combinations in the diagnostic
code field shall not cause the DTE to not accept the cause field.
PAGE70 Fascicle VIII.8 - X.25
5.4.4 DTE and DCE reset confirmation packets
Figure 16/X.25 illustrates the format of the DTE and DCE reset
confirmation packets.
Bits
8 7 6 5 4 3 2 1
Octets
1 General format identifier (see Logical channel group number
Note)
2 Logical channel number
3 Packet type identifier
0 0 0 1
Fascicle VIII.2 - Rec. X.25 PAGE93
1 1 1 1
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 16/X.25
DTE and DCE reste confirmation packet format
5.5 Restart packets
5.5.1 Restart request and restart indication packets
Figure 17/X.25 illustrates the format of the restart request and restart
indication packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) 0 0 0
PAGE70 Fascicle VIII.8 - X.25
0
2 0 0 0 0 0 0 0 0
3 Packet type identifier
1 1 1 1 1 0 1 1
4 Restarting cause
5 Diagnostic code a)
a) This field is not mandatory in restart request packets.
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 17/X.25
Restart request and restart indication packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.5.1.1 Restarting cause field
Octet 4 is the restarting cause field and contains the reason for the
restart.
In restart request packets, the restarting cause field should be set by
the DTE to one of the following values:
bits: 8 7 6 5 4 3 2 1
value: 0 0 0 0 0 0 0 0
or: 1 X X X X X X X
where each X may be independently set to 0 or 1 by the DTE.
The DCE will prevent values of the restarting cause field, other than
those shown above, from reaching the other end of the virtual calls and/or
permanent virtual circuits by either accepting the restart request packet and
forcing the clearing or resetting cause field to all zeros in the corresponding
clear and/or reset indication packets, or considering the restart request as an
error and following the procedure described in Annex C.
The coding of the restarting cause field in the restart indication packets
is given in Table 22/X.25.
TABLE 22/X.25
Coding of restarting cause field in restart indication packet
Bits
8 7 6 5 4 3 2 1
Local procedure error 0 0 0 0 0 0 0 1
Network congestion 0 0 0 0 0
PAGE70 Fascicle VIII.8 - X.25
0 1 1
Network operational 0 0 0 0 0 1 1 1
Registration/cancellation 0 1 1 1 1 1 1 1
confirmed a)
a) May be received only if the optional on-line facility registration
facility is used.
5.5.1.2 Diagnostic code
Octet 5 is the diagnostic code and contains additional information on the
reason for the restart.
In a restart request packet, the diagnostic code is not mandatory. The
diagnostic code, if specified, is passed to the corresponding DTEs as the
diagnostic code of a reset indication packet for permanent virtual circuits or a
clear indication packet for virtual calls.
The coding of the diagnostic code field in a restart indication packet is
given in Annex E. The bits of the diagnostic code are all set to zero when no
specific additional information for the restart is supplied.
Note - The contents of the diagnostic code field do not alter the meaning
of the cause field. A DTE is not required to undertake any action on the contents
of the diagnostic code field. Unspecified code combinations in the diagnostic
code field shall not cause the DTE to not accept the cause field.
Fascicle VIII.2 - Rec. X.25 PAGE93
5.5.2 DTE and DCE restart confirmation packets
Figure 18/X.25 illustrates the format of the DTE and DCE restart
confirmation packets.
Bits
8 7 6 5 4 3 2 1
Octet
s
1 General format identifier (see Note) 0 0 0 0
2 0 0 0 0 0
PAGE70 Fascicle VIII.8 - X.25
0 0 0
3 Packet type identifier
1 1 1 1 1 1 1 1
Note - Coded 0001 (modulo 8) or 0010 (modulo 128).
FIGURE 18/X.25
DTE and DCE restart confirmation packet format
5.6 Diagnostic packet
Figure 19/X.25 illustrates the format of the diagnostic packet.
Bits
8 7 6 5 4 3 2 1
Octet
s
Fascicle VIII.2 - Rec. X.25 PAGE93
1 General format identifier (see Note 0 0 0 0
1)
2 0 0 0 0 0 0 0 0
3 Packet type identifier
1 1 1 1 0 0 0 1
4 Diagnostic code
5 Diagnostic explanation (see Note 2)
PAGE70 Fascicle VIII.8 - X.25
Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128).
Note 2 - The figure is drawn assuming the diagnostic explanation field is an integral
number of octets in length.
FIGURE 19/X.25
Diagnostic packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.6.1 Diagnostic code field
Octet 4 is the diagnostic code and contains information on the error
condition which resulted in the transmission of the diagnostic packet. The coding
of the diagnostic code field is given in Annex E.
5.6.2 Diagnostic explanation field
When the diagnostic packet is issued as a result of the reception of an
erroneous packet from the DTE (see Tables C-1/X.25 and C-2/X.25), this field
contains the first three octets of header information from the erroneous DTE
packet. If the packet contains less than 3 octets, this field contains whatever
bits were received.
When the diagnostic packet is issued as a result of a DCE time-out (see
Table D-1/X.25), the diagnostic explanation field contains 2 octets coded as
follows:
- bits 8, 7, 6 and 5 of the first octet contain the general format
identifier for the interface;
- bits 4 to 1 of the first octet and bits 8 to 1 of the second octet are
all 0 for expiration of time-out T10 and give the number of the logical
channel on which the time-out occurred for expiration of time-out T12
or T13.
5.7 Packets required for optional user facilities
5.7.1 DTE reject (REJ) packet for the packet retransmission facility
Figure 20/X.25 illustrates the format of the DTE REJ packet, used in
conjunction with the packet retransmission facility described in S 6.4.
Bits
8 7 6 5 4 3 2 1
Octets
1 General format identifier Logical channel group number
0 0 0
PAGE70 Fascicle VIII.8 - X.25
1
2 Logical channel number
3 Packet type identifier
P(R) 0 1 0 0 1
(Modulo
8)
Bits
8 7 6
Fascicle VIII.2 - Rec. X.25 PAGE93
5 4 3 2 1
Octets
1 General format identifier Logical channel group number
0 0 1 0
2 Logical channel number
3 Packet type identifier
0 0
PAGE70 Fascicle VIII.8 - X.25
0 0 1 0 0 1
4 P(R) 0
(When extended to modulo 128)
FIGURE 20/X.25
DTE REJ packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.7.1.1 Packet receive sequence number
Bits 8, 7 and 6 of octet 3, or bits 8 through 2 of octet 4 when extended,
are used for indicating the packet receive sequence number P(R). P(R) is binary
coded and bit 6, or bit 2 when extended, is the low order bit.
5.7.2 Registration packets for the on-li e facility registration
facility
5.7.2.1 Registration request packet
Figure 21/X.25 illustrates the format of the registrat e s t
packet.
Bits
8 7 6 5 4 3 2 1
Octets
1 General format identifier (see Note 1) 0 0 0 0
2 0 0 0
PAGE70 Fascicle VIII.8 - X.25
0 0 0 0 0
3 Packet type identifier
1 1 1 1 0 0 1 1
4 DTE address length DCE address length
DCE and DTE address(es) (see Note 2)
0 0 0 0
0 Registration length
Fascicle VIII.2 - Rec. X.25 PAGE93
Registration
Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128).
Note 2 - The figure is drawn assuming the total number of address digits present is odd.
FIGURE 21/X.25
Registration request packet format
5.7.2.1.1 Address length fields
Octet 4 consists of the field length indicators for the DTE and DCE
addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE address in
semi-octets. Bits 8, 7, 6 and 5 indicate the length of the DTE address in
semi-octets. Each address length indicator is binary coded and bit 1 or 5 is the
low order bit of the indicator.
These fields are coded with all zeros under the procedures in this
Recommendation.
5.7.2.1.2 Address field
Octet 5 and the following octets consist of the DCE address, when present,
and the DTE address, when present.
Each digit of an address is coded in a semi-octet in binary coded decimal
with bit 5 or 1 being the low order bit of the digit.
PAGE70 Fascicle VIII.8 - X.25
Starting from the high order digit, the address is coded in octet 5 and
consecutive octets with two digits per octet. In each octet, the higher order
digit is coded in bits 8, 7, 6 and 5.
The address field shall be rounded up to an integral number of octets by
inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when
necessary.
This field is not present under the procedures in this Recommendation.
5.7.2.1.3 Registration length field
The octet following the address field indicates the length of the
registration field in octets. The registration length indicator is binary coded
and bit 1 is the low order bit of the indicator.
5.7.2.1.4 Registration field
The registration field is present only when the DTE wishes to request the
DCE to agree to, or to stop a previous agreement for, an optional user facility.
The coding of the registration field is defined in S 7.3.
The registration field contains an integral number of octets. The actual
maximum length of this field depends on the network. However, this maximum does
not exceed 109 octets.
5.7.2.2 Registration confirmation packet
Figure 18/X.25 illustrates the format of the registration confirmation
packet.
Bits
8 7 6 5 4 3 2 1
Octets
1 General format identifier (see Note 1) 0 0 0 0
2 0 0 0
Fascicle VIII.2 - Rec. X.25 PAGE93
0 0 0 0 0
3 Packet type identifier
1 1 1 1 0 0 1 1
Cause
Diagnostic
4 DTE address length DCE address length
DCE and DTE address(es) (see Note 2)
0 0 0
PAGE70 Fascicle VIII.8 - X.25
0
0 Registration length
Registration
Note 1 - Coded 0001 (modulo 8) or 0010 (modulo 128).
Note 2 - The figure is drawn assuming the total number of address digits present is odd.
FIGURE 22/X.25
Registration confirmation packet format
Fascicle VIII.2 - Rec. X.25 PAGE93
5.7.2.2.1 Cause field
Octet 4 is the cause field and contains the cause of any failure in
negotiation of facilities or an indication that the registration field was
verified by the DCE.
The coding of the cause field in the registration confirmation packet is
shown in Table 23/X.25.
TABLE 23/X.25
Coding of cause field in registration confirmation packet
Bits
8 7 6 5 4 3 2 1
Registration/cancellation confirmed 0 1 1 1 1 1 1 1
Invalid facility request 0 0 0 0 0 0 1 1
Local procedure error
PAGE70 Fascicle VIII.8 - X.25
0 0 0 1 0 0 1 1
Network congestion 0 0 0 0 0 1 0 1
5.7.2.2.2 Diagnostic code
Octet 5 is the diagnostic code and contains additional information on the
reason for failure of facilities negotiation.
Annex E lists the coding for diagnostics. The bits of the diagnostic code
are all set to 0 when negotiation is successful, or when no additional
information is supplied.
5.7.2.2.3 Address length fields
Octet 6 consists of the field length indicators for the DTE and DCE
addresses. Bits 4, 3, 2 and 1 indicate the length of the DCE address in
semi-octets. Bits 8, 7, 6 and 5 indicate the length of the DTE address in
semi-octets. Each address length indicator is binary coded and bit 1 or 5 is the
low order bit of the indicator.
These fields are coded with all zeros under the procedures in this
Recommendation.
5.7.2.2.4 Address field
Octet 7 and the following octets consist of the DCE address, when present,
and the DTE address, when present.
Each digit of an address is coded in a semi-octet in binary coded decimal
with bit 5 or 1 being the low order bit of the digit.
Starting from the high order digit, the address is coded in octet 7 and
consecutive octets with two digits per octet. In each octet, the higher order
digit is coded in bits 8, 7, 6 and 5.
The address field shall be rounded up to an integral number of octets by
inserting zeros in bits 4, 3, 2 and 1 of the last octet of the field when
necessary.
This field is not present under the procedures in this Recommendation.
5.7.2.2.5 Registration length field
The octet following the address field indicates the length of the
registration field, in octets. The registration length indicator is binary coded
and bit 1 is the low order bit of the indicator.
5.7.2.2.6 Registration field
The registration field is used to indicate which optional user facilities
are available, and which are currently in effect.
The coding of the registration field is defined in S 7.3.
The registration field contains an integral number of octets. The actual
maximum length of this field depends on the network. However, this maximum does
not exceed 109 octets.
6 Procedures for optional user facilities (packet layer)
6.1 On-line facility registration
On-line facility registration is an optional user facility agreed for a
period of time. This facility, if subscribed to, permits the DTE at any time to
request registration of facilities, or obtain current values of facilities as
understood by the DCE, by transferring across the DTE/DCE interface a
registration request packet.
The DCE will, in response to a registration packet, report the current
value of all facilities applicable to the DTE/DCE interface, by transferring a
registration confirmation packet across the DTE/DCE interface. Optional
facilities which are not offered by the network will not be reported in the
registration confirmation packet. To avoid requesting facilities that are not
available in a particular network, or values that are not allowed, the DTE may
transfer a registration request packet across the DTE/DCE interface containing no
optional facilities. It may then modify any negotiable facilities reported in the
corresponding registration confirmation packet by transferring a second
registration request packet across the DTE/DCE interface.
When the DCE returns the registration confirmation packet, the facilities
values shown are in effect for any subsequent virtual calls. The values of the
extended packet sequence numbering, packet retransmission, and D bit modification
facilities and the allocation of logical channel type ranges can be modified only
when there are no virtual calls (i.e., all logical channels used for virtual
calls are in state p1). When these facilities take effect and when there is one
or more logical channels assigned to permanent virtual circuits, the network
restarts the interface with the cause "Registration/cancellation confirmed" and
the diagnostic "No additional information" in order to change the values of the
Fascicle VIII.2 - Rec. X.25 PAGE93
permanent virtual circuits at the interface. At the remote end of each permanent
virtual circuit, the corresponding reset indication packet is sent with the cause
"Remote DTE operational" and the diagnostic "No additional information".
If a requested value of a particular facility is not allowed, the DCE
shall report in the registration confirmation packet:
a) if the facility has a boolean value, the value allowed;
b) if the value is greater than the maximum allowed value of that
facility, the maximum allowed value; or
c) if the value is less than the minimum allowed value of that facility,
the minimum allowed value.
The registration confirmation packet shall also contain an appropriate
cause code. The DTE may choose to accept the value reported by the DCE or to
attempt to negotiate another value for the requested facilities.
If the DCE cannot make all the modifications requested in a registration
request packet, it will not alter the values of some facilities. Circumstances in
which the DCE can not make all of the modifications requested include:
a) conflict in facilities settings, and
b) when the interface has at least one virtual call established when
attempting to negotiate those facilities that require all virtual call
logical channels to be in state p1 (including the collision of an
incoming call packet and a registration request packet).
The DTE should wait for the registration confirmation packet before
sending a call request packet, or sending a packet on a permanent virtual
circuit.
For every optional user facility, Annex F indicates:
- if the value of the facility may be negotiated;
- if the registration confirmation packets indicate whether or not the
facility is supported by the DCE;
- if the value of the facility may be altered by the DTE either only when
every logical channel used for virtual calls is in state p1, or in any
packet layer state.
Indication in registration confirmation packet of whether the NUI override
facility is supported by the network is for further study.
A fault condition within the network may affect the facilities previously
negotiated by means of registration packets. In this situation, the DCE initiates
the restart procedure to inform the DTE of the failure.
A restart procedure initiated by the DTE does not affect the facilities
values. When the DCE initiates the restart procedure with the cause "Local
procedure error", the facilities values are not affected. When the DCE initiates
the restart procedure with the cause "Network congestion" or "Network
operational", the values of facilities previously negotiated may be affected.
When the DCE initiates the restart procedure with the cause
"Registration/cancellation confirmed", the facilities values are as set by the
related registration procedure.
6.2 Extended packet sequence numbering
Extended packet sequence numbering is an optional user facility agreed for
a period of time. It is common to all logical channels at the DTE/DCE interface.
This user facility, if subscribed to, provides sequence numbering of
packets performed modulo 128. In the absence of this facility, the sequence
numbering of packets is performed modulo 8.
6.3 D bit modification
D bit modification is an optional user facility agreed for a period of
time. This facility applies to all virtual calls and permanent virtual circuits
at the DTE/DCE interface. This facility is only intended for use by those DTEs
implemented prior to the introduction of the D bit procedure which were designed
for operation on public data networks that support end-to-end P(R) significance.
It allows these DTEs to continue to operate with end-to-end P(R) significance
within a national network.
For communication within the national network, this facility, when
subscribed to:
a) will change from 0 to 1 the value of bit 7 of the GFI in all call
request and call accepted packets and the value of the D bit in all DTE
data packets received from the DTE, and
b) will set to 0 the value of bit 7 of the GFI in all incoming call and
call connected packets, and the value of the D bit in all DCE data
PAGE70 Fascicle VIII.8 - X.25
packets transmitted to the DTE.
For international operation, conversion b) above applies and conversion a)
above does not apply. Other conversion rules for international operation are for
bilateral agreement between Administrations.
6.4 Packet retransmission
Packet retransmission is an optional user facility agreed for a period of
time. It is common to all logical channels at the DTE/DCE interface.
This user facility, if subscribed to, allows a DTE to request
retransmission of one or several consecutive DCE data packets from the DCE by
transferring across the DTE/DCE interface a DTE reject packet specifying a
logical channel number and a sequence number P(R). The value of this P(R) should
be within the range from the last P(R) received by the DCE up to, but not
including, the P(S) of the next DCE data packet to be transmitted by the DCE. If
the P(R) is outside this range, the DCE will initiate the reset procedure with
the cause "Local procedure error" and diagnostic ## 2.
When receiving a DTE reject packet, the DCE initiates on the specified
logical channel retransmission of the DCE data packets, the packet send sequence
numbers of which are starting from P(R), where P(R) is indicated in the DTE
reject packet. Until the DCE transfers across the DTE/DCE interface a DCE data
packet with a packet send sequence number equal to the P(R) indicated in the DTE
reject packet, the DCE will consider the receipt of another DTE reject packet as
a procedure error and reset the logical channel.
Additional DCE data packets pending initial transmission may follow the
retransmitted packet(s).
A DTE receive not ready situation indicated by the transmission of an RNR
packet is cleared by the transmission of a DTE reject packet.
The conditions under which the DCE ignores a DTE reject packet, or
considers it as a procedure error, are those described for flow control packets
(see Annex C).
6.5 Incoming calls barred
Incoming calls barred is an optional user facility agreed for a period of
time. This facility applies to all logical channels used at the DTE/DCE interface
for virtual calls.
This user facility, if subscribed to, prevents incoming virtual calls from
being presented to the DTE. The DTE may originate outgoing virtual calls.
Note 1 - Logical channels used for virtual calls retain their full duplex
capability.
Note 2 - Some Administrations may provide a capability that allows a
virtual call to be presented to the DTE only in cases where the called DTE
address is the address of the calling DTE.
6.6 Outgoing calls barred
Outgoing calls barred is an optional user facility agreed for a period of
time. This facility applies to all logical channels used at the DTE/DCE interface
for virtual calls.
This user facility, if subscribed to, prevents the DCE from accepting
outgoing virtual calls from the DTE. The DTE may receive incoming virtual calls.
Note - Logical channels used for virtual calls retain their full duplex
capability.
6.7 One-way logical channel outgoing
One-way logical channel outgoing is an optional user facility agreed for a
period of time. This user facility, if subscribed to, restricts the logical
channel use to originating outgoing virtual calls only.
Note - A logical channel used for virtual calls retains its full duplex
capability.
The rules according to which logical channel group numbers and logical
channel numbers can be assigned to one-way outgoing logical channels for virtual
calls are given in Annex A.
Note - If all the logical channels for virtual calls are one-way outgoing
at a DTE/DCE interface, the effect is equivalent to the incoming calls barred
facility (see S 6.5, particularly Note 2).
6.8 One-way logical channel incoming
One-way logical channel incoming is an optional user facility agreed for a
period of time. This user facility, if subscribed to, restricts the logical
channel use to receiving incoming virtual calls only.
Note - A logical channel used for virtual calls retains its full duplex
Fascicle VIII.2 - Rec. X.25 PAGE93
capability.
The rules according to which logical channel group numbers and logical
channel numbers can be assigned to one-way incoming logical channels for virtual
calls are given in Annex A.
Note - If all the logical channels for virtual calls are one-way incoming
at a DTE/DCE interface, the effect is equivalent to the outgoing calls barred
facility (see S 6.6).
6.9 Non-standard default packet sizes
Non-standard default packet sizes is an optional user facility agreed for
a period of time. This facility, if subscribed to, provides for the selection of
default packet sizes from the list of packet sizes supported by the
Administration. Some networks may constrain the packet sizes to be the same for
each direction of data transmission across the DTE/DCE interface. In the absence
of this facility, the default packet sizes are 128 octets.
Note - In this section, the term "packet sizes" refers to the maximum user
data field lengths ofDCE data and DTE data packets.
Values other than the default packet sizes may be negotiated for a virtual
call by means of the flow control parameter negotiation facility (see S 6.12).
Values other than the default packet sizes may be agreed for a period of time for
each permanent virtual circuit.
6.10 Non-standard default window sizes
Non-standard default window sizes is an optional user facility agreed for
a period of time. This facility, if subscribed to, provides for the selection of
default window sizes from the list of window sizes supported by the
Administration. Some networks may constrain the default window sizes to be the
same for each direction of data transmission across the DTE/DCE interface. In the
absence of this facility, the default windonw sizes are 2.
Values other than the default window sizes may be negotiated for a virtual
call by means of the flow control parameter negotiation facility (see S 12).
Values other than the default window sizes may be agreed for a period of time for
each permanent virtual circuit.
6.11 Default throughput classes assignment
Default throughput classes assignment is an optional user facility agreed
for a period of time. This facility, if subscribed to, provides for the selection
of default throughput classes from the list of throughput classes supported by
the Administration. Some networks may constrain the default throughput classes to
be the same for each direction of data transmission. In the absence of this
facility, the default throughput classes correspond to the user class of service
of the DTE (see S 7.2.2.2) but do not exceed the maximum throughput class
supported by the network.
The default throughput classes are the maximum throughput classes which
may be associated with any virtual call at the DTE/DCE interface. Values other
than the default throughput classes may be negotiated for a virtual call by means
of the throughput class negotiation facility (see S 6.13). Values other than the
default throughput classes may be agreed for a period of time for each permanent
virtual circuit.
Note - Throughput characteristics and throughput class are described in S
4.4.2.
6.12 Flow control parameter negotiation
Flow control parameter negotiation is an optional user facility agreed for
a period of time which can be used by a DTE for virtual calls. This facility, if
subscribed to, permits negotiation on a per call basis of the flow control
parameters. The flow control parameters considered are the packet and window
sizes at the DTE/DCE interface for each direction of data transmission.
Note - In this section, the term "packet sizes" refers to the maximum user
data field lengths of DCE data and DTE data packets.
In the absence of the flow control parameter negotiation facility, the
flow control parameters to be used at a particular DTE/DCE interface are the
default packet sizes (see S 6.9) and the default window sizes (see S 6.10).
When the calling DTE has subscribed to the flow control parameter
negotiation facility, it may request packet sizes and/or window sizes for both
direction of data transmission (see SS 7.2.1 and 7.2.2.1). If particular window
sizes are not explicitly requested in acall request packet, the DCE will assume
that the default window sizes were requested for both directions of data
transmission. If particular packet sizes are not explicitly requested, the DCE
PAGE70 Fascicle VIII.8 - X.25
will assume that the default packet sizes were requested for both directions of
data transmission.
When a called DTE has subscribed to the flow control parameter negotiation
facility, each incoming call packet will indicate the packet and window sizes
from which DTE negotiation can start. No relationship needs to exist between the
packet sizes (P) and window sizes (W) requested in the call request packet and
those indicated in the incoming call packet. The called DTE may request window
and packet sizes with facility in the call accepted packet. The only valid
facility requests in the call accepted packet, as a function of the facility
indications in the incoming call packet, are given in Table 24/X.25. If the
facility request is not made in the call accepted packet, the DTE is assumed to
have accepted the indicated values (regardless of the default values) for both
directions of data transmission.
TABLE 24/X.25
Valid facility requests in call accepted packets in response to facility indications in
incoming call packets
Facility indication Valid facility request
W(indicated) 2 W(indicated) W(requested) 2
W(indicated) = 1 W(requested) = 1 or 2
P(indicated) 128 P(indicated) P(requested) 128
P(indicated) < 128 128 P(requested) P(indicated)
When the calling DTE has subscribed to the flow control parameter
negotiation facility, every call connected packet will indicate the packet and
window sizes to be used at the DTE/DCE interface for the call. The only valid
facility indications in the call connected packet, as a function of the facility
requests in the call request packet, are given in Table 25/X.25.
TABLE 25/X.25
Valid facility indications in call connected packets in response to facility requests in
call request packets
Facility indication Valid facility request
W(requested) 2 W(requested) W(indicated) 2
W(requested) = 1 W(indicated) = 1 or 2
P(requested) 128 P(requested) P(indicated) 128
P(requested) < 128 128 P(indicated) P(requested)
The network may have constraints requiring the flow control parameters
used for a call to be modified before indicating them to the DTE in the incoming
call packet or call connected packet; e.g., the ranges of parameter values
available on various networks may differ.
Window and packet sizes need not be the same at each end of a virtual
call.
The role of the DCE in negotiating the flow control parameters may be
network dependent.
6.13 Throughput class negotiation
Throughput class negotiation is an optional user facility agreed for a
period of time which can be used by a DTE for virtual calls. This facility, if
subscribed to, permits negotiation on a per call basis of the throughput classes.
The throughput classes are considered independently for each direction of data
transmission.
Default values are agreed between the DTE and the Administration (see S
6.11). The default values correspond to the maximum throughput classes which may
be associated with any virtual call at the DTE/DCE interface.
When the calling DTE has subscribed to the throughput class negotiation
facility, it may request the throughput classes of the virtual call in the call
request packet for both directions of data transmission (see SS 7.2.1 and
7.2.2.2). If particular throughput classes are not explicitly requested, the DCE
will assume that the default values were requested for both directions of data
transmission.
When a called DTE has subscribed to the throughput class negotiation
facility, each incoming call packet will indicate the throughput classes from
which DTE negotiation may start. These throughput classes are lower or equal to
the ones selected at the calling DTE/DCE interface, either explicitly, or by
default if the calling DTE has not
Fascicle VIII.2 - Rec. X.25 PAGE93
subscribed to the throughput class negotiation facility or not explicitly
requested throughput class values in the call request packet. These throughput
classes indicated to the called DTE will also not be higher than the default
throughput classes, respectively for each direction of data transmission, at the
calling and the called DTE/DCE interfaces. They may be further constrained by
internal limitations of the network.
The called DTE may request with a facility in the call accepted packet
throughput classes that should finally apply to the virtual call. The only valid
throughput classes in the call accepted packet are lower than or equal to the
ones (respectively) indicated in the incoming call packet. If the called DTE does
not make any throughput class facility request in the call accepted packet, the
throughput classes finally applying to the virtual call will be the ones
indicated in the incoming call packet.
If the called DTE has not subscribed to the throughput class negotiation
facility, the throughput classes finally applying to the virtual call are less
than or equal to the ones selected at the calling DTE/DCE interface, and less
than or equal to the default values defined at the called DTE/DCE interface.
When the calling DTE has subscribed to the throughput class negotiation
facility, every call connected packet will indicate the throughput classes
finally applying to the virtual call.
When neither the calling DTE nor the called DTE has subscribed to the
throughput class negotiation facility, the throughput classes applying to the
virtual call will not be higher than the ones agreed as defaults at the calling
and called DTE/DCE interfaces. They may be further constrained to lower values by
the network, e.g., for international service.
Note 1 - Since both throughput class negotiation and flow control
parameter negotiation (see S 6.12) facilities can be applied to a single call,
the achievable throughput will depend on how users manipulate the D bit.
Note 2 - Users are cautioned that the choice of too small a window and
packet size of a DTE/DCE interface (made by use of the flow control parameter
negotiation facility may adversely affect the attainable throughput class of a
virtual call. This is likewise true of flow control mechanisms adopted by the DTE
to control data transmission from the DCE.
6.14 Closed user group related facilities
A set of closed user group (CUG) optional user facilities enables users to
form groups of DTEs to and/or from which access is restricted. Different
combinations of access restrictions to and/or from DTEs having one or more of
these facilities result in various combinations of accessibility.
A DTE may belong to one or more CUGs. Each DTE belonging to at least one
CUG has either the closed user group facility (see S 6.14.1) or one or both of
the closed user group with outgoing access and the closed user group with
incoming access facilities (see SS 6.14.2 and 6.14.3). For each CUG to which a
DTE belongs, either none of the incoming calls barred within a closed user group
or the outgoing calls barred within a closed user group facilities (see SS 6.14.4
and 6.14.5) may apply for that DTE. Different combinations of CUG facilities may
apply for different DTEs belonging to the same CUG.
When a DTE belonging to one or more CUGs places a virtual call, the DTE
may explicitly indicate in the call request packet the CUG selected by using the
closed user group selection facility (see S 6.14.6) or the closed user group with
outgoing access selection facility (see S 6.14.7) (see Note). When a DTE
belonging to one or more CUGs receives a virtual call, the CUG selected may be
explicitly indicated in the incoming call packet through the use of the closed
user group selection facility or the closed user group with outgoing access
selection facility.
Note - For a given virtual call, only one of the above-mentioned selection
facilities can be present.
The number of CUGs to which a DTE can belong is network dependent.
6.14.1 Closed user group
Closed user group is an optional user facility agreed for a period of time
for virtual calls. This user facility, if subscribed to, enables the DTE to
belong to one or more closed user groups. A closed user group permits the DTEs
belonging to the group to communicate with each other but precludes communication
with all other DTEs.
When the DTE belongs to more than one closed user group, a preferential
closed user group must be specified.
PAGE70 Fascicle VIII.8 - X.25
